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(57) Abstract: An online machine data collection 
and archiving process (15) generates a machine data 
profile (18) of a customer computer (5) accessing a 
transaction form of a merchant web site (3) and links the 
machine data profile (18) and a transaction record (6) 
with customer identifying information using a unique 
transaction identification string. The process preferably 
captures parameters typically communicated as part of 
web accesses, such as an IP address, an HTTP header, 
and cookie information. The process additionally causes 
the customer computer (5) to process self -identification 
routines by processing coding within the merchant 
transaction form, the self-identification routines 
5delding further profile parameters. The process further 
includes a routine for bypassing an intervening proxy 
to the merchant web site (3) to reveal the true IP address 
of the customer computer (5). 
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1 OMLlI«;MACmSEDAT^ 
2 

3 Cross^Reference to Pravisionat Application 

4 This appficaticm claims benefits fi^om provisional application. Serial Ko. 

5 60/209,936 filed June 7, 2000 and entitled METHOD FOR COLDSCTmomCHINB 

6 DATAEROMdUSTOMERSONAC^ 

7 • 

8 Background of the laventioM 

9 The present invention relates to identity detection techmq^ 

1 0 particulady, to a process for collecting and utilidng machine-identi^dng data of conq>uters 

11 and otiier online appliances used in online interactions and transactions and: assodating the 

1 2 collected machine data with such online interactions. 

13 The hitemet, or global computer netwoifc, represents a new mediumfbr marioeting 

14 shnilar to the way niailorderii^ and telephone ordering c^^ Adownsideof 

15 int^et marketing is that it also presents new opportunities for unscrupulous persons to 

1 6 take advantage of the mechanisms of internet transactions by fraudulent and deceptive 

1 7 practices, ^ferdiants and financial institutions bear the initiM costs of fiaud. However, 

1 8 consume uttunat^y pay the costs in the form of prices and credit rates winch must take 

19 into account losses from fraud. Internet purchases tyjncally kvolve tlie use of w^ p^ge 

20 forms wlxich are filled in by the customer witii identity, address, purchase, shippmi^ and 

1 
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1 payment in&nnation and submitted to the online merchant for processing. Internet 

2 purchases are most often paid fbr by ws3r of credit cards. While a merdiant*s software 

3 may be able to verify the existence and status of a credit card account number and an 

4 authorizatioii for a specific amount, the merdiant is ottm not able to match a (aedit card 

5 mmiber with a specific purchaser or shippiqg address. Thu^ absent any overt indication 

6 otherwise, a merchant generally assumes that aiqrone using a credit card is authorized to 

7 do so and that a customer is v/bo he identifies himself to be. 

8 An important step in combating fiaud is accurate identification of the computers 

9 throt^ which customers mate transactions and associating such identities with ' 
transactions which arouse suspicions or whidi ultimately turn out to be fi:audulent Basic 
madune identify is essential to tiiemamiermimbi(A the internet oper^. Wespeakin 
termsof"going"toawebstte. Jnreality, "goin^ to a web site involves sending a request 
fi>r a web page file in a (firectoiy orfi)lder on a computer located at a spedfic internet 
proto^l, or IP, address. In order fi>r the web page file to be returned to the request^ 
computer for processing into a displayed "web page", the request must inchide return 
''directions" in the form of the basic identity of tiie requesting con^uter, mcluding its IP 
address. Some web sites are unplemented witii soflware which enables responses to web 
page requests to be tailored to spedfics of tiie requesting niachbe's configuration, spedfic 
web browser, and the like. For this reason, current versions of browsers usually 
commu n i c ate con^guration mfiMmation in addition to a return IP address and return patL 
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1 The IF address of a page requesting computer can give an indication of the specific 

2 country where the computer is located * Ftirther, identification of a page*requesting 

3 computer can also recognize a returning user u^g the same computer as during a 

4 previous access. For example, placing an HTTP (hyp^text transfer protocol) ^cookie" on 

5 a page-requestmg computer can make it possible to identify tibie compiiter on a later 

6 access. 

7 Because direct interaction \vith a customer's computer is essratial in detei^^ 

8 firaud, it has been assimied that any viable firaud detection software must be integrated Tvith 

9 a merdiant's software. As a r^t, most existing fi'aud detection solutions require 

1 0 merchants to either abandon or extensively modify their existing web-based transaction 

11 processing sofiwarc; An additional probl^ with fdcusmgfiauddetectioii at single 

12 merchants is that perpetrators of fiaud often hit many m^chants in an att^pt to avoid or 

1 3 delay detection. Hius, an ideal system for fiaiid detection in onlme marketing would onfy 

14 minhnally afifect the mediant's existir^ software and would route ftaud detection eftbrta 

1 5 through a central, third-parfy entity serving a large multitude of merchants. 
16 

17 Snmmarv of the Invention 

18 The preset mventionpn)vides a pn)cess for cottecdbig data assod^ 

19 customer's compute* during access of amerdiant, financial, oth^host web site, and 

20 assodatmg a transaction identification numb^witii the data and with a transact 

21 tfaemeidiant. GeneraUy, the presort invoition captures rnacfameidentifyiii^ 
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1 computer or other digital appKance accessiag a host web site, sends the captured data to a 

2 machiae data archive along with a umquetransac**onidaitificatio^ 

3 arcMve and writes the same transaction identification string kto a transact 

4 through ^di transactions with the host web site are conducted. The machine data is, 

5 thus, assodated with the customer identification data withm the transaction ioan by wi^ 

6 of the transaction id^itification string and can be used on-the-fly or at a later time for a 

7 variety ofpuiposesinduding, but not lunited to, fimid detection. Although the teim 

8 ''an^e" is used, tile madime data collected need not be stored permanently. 

9 The machine data coBectibn process ofthepreseaitmvention is intend 

10 employed in a variety ofappllcationsindudm& but not limited to: online purchases and 

11 orders; onlhie banking, bill paymaaty and fimds transfers; online registrations, such asfi)r 

12 memboships, product wananties, applications fijr <xe£t, mismd. of subscriptions and 

13 license^ online tedmicat support; and the like. The term "transaction" is used m tike 

14 pi^ent invention to descnl}e an toteractioneflSMJted between a digital (^liancea^ 

15 system. However, the term '^ansaction" is not hitended to be restrided to only 

16 commerdal interactions involving purchases. The term "transaction" is intended to apply 

17 to an interaction of a r^ote digital appliance with a host syst^ usung a idativdy 

1 8 anoiQraous type of access process over a digital medhnn to'wfaich some form of sdf- 

19 identification ofthe accessing appliance is hiherem in the access process and in 

20 tree itoifyoftheaccesshig party, the true souiw address of the appl^^ 
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1 medium, and/or the true machine characteristics of the accessing appliance is/are essential 

2 or de^rable to the interaction. 

3 The host entity which operates the host system accessed is intended to encompass 

4 a commercial, financial, educational, governmental, assodational, or other ^e of entily. 

5 The term "Merchant'' will be used herein to refer to such a host entity wi^out mtent to 

6 limit the present invention to commerdal transactions. The mediimi of access is intended 

7 to be interpreted as including a global computer network such as the intemet or world 

8 wide web, as well as other types of networks whidb may be less than global but which are 

9 publicly and/or anoiQrmously accessible. The term "Intemef will be used h^^ to refer 

10 to the medhmi through wMch accesses to the host entity are made. The totms ''customer 

11 compute' or ''madiine" are used herein to refer to a device for effecting r^note access to 

12 a host system over a diktat medum and are meant to encompass not only conventional 

1 3 types of personal computers, but also additional types of ''digital appliances" with online 

14 access capabilities, such as: cdl phones, personal distal assistant devices, dtectromcga^ 

1 5 ^sterns, television sets with online access capabilities, web appliances for vehicles, and 

1 6 any other type of device with online access capabilities whether connected to a wired 

1 7 communications network: directly or by a radiant tedmology. 

1 8 ' The machine data collection process of the present hivmtion contemplates a two 

1 9 party process embodiment in which a "^merdianf ' processes and/or stores machine data 
2 0 profiles of customer computers in-house, as well as a three party process embodiment in 
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1 which machine data profiles of oistomer computers are processed and/pr stored for the 

2 merest t>y a third-party nuchine data eottection and an^ve service. 

3 In a two party embodiment of the data collection process of the preset inventiofl^ 

4 the customer madiine data is captured by a merchant or host system which also generates 

5 a unique transaction identification (ID) strung and assigns or assodates the tians^ 

6 with a madbine data profile oftiie customs machine dBta profile. Ih^twoparfy 

7 process^ the m«:diant system captures c^ stomeroonq)uter data wM^ 

8 fiom the customer computer to tiie merdbanVs vrdb site^ such as an IP address of the 

9 cus|om^ conq>ut^ and an Jttrir h^der. Additionally, according to tiie preseol 

1 0 invention, the merchant w^ page code may have routines or calls for external routines 

11 which, when processed by the custom^ conqmter, cause the customer conopit^ to 

12 iurtho: identify itselfbycoUecting and retuniing c^tain machine and sofiware 

13 configuration charactoistics, vMck can be used to identify tiie particular customer 

14 computer. The two party process may indude the generation and setting of an HITP 

15 coolde hi the customs browser for recogrftion upon a later access Mukh the mayhflpt web 

16 dte. 

1 7 Although the two-party embodunent of the madiine data collection process of the 

1 8 pres^ invention has utility for some applications, the three party embodunoit is pre&ned 

19 for appfications in whidianalyfMsofa maximum number of customer computer pro^ 
.20 deskMe, sudi as certam types of maiketimg processes and finud detection and contiol 
21 processes. In a three emboditneotofthepiesem invention, the customer madihidda^ 
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1 computers accessing the second party or merchant web site is communicated to and stoneid 

2 \vithin a third party ^tem» referred to herein as a machine data ardiives^ce. fiithe 

3 three party process, the transaction ID could be generated by the merchant system, but is 

4 preferably generated by the archive service. The use of the tenn "archive" is not meant to 
5 . indicate ttiat the customer machine data profiles are stored permanently i;vttbin the third 

6 party system. Permanent storage of such profiles may not be practical, as &r as yieldmg 

7 braieficial results to the purposes for which the profiles are collected Thus, the term 

8 ""arcMve'Ms meant to indicate a centrd storage &dHty,sudi as a database, a sel^ 

9 retention period, with purging of most profiles after a obtain length of time. 

10 In the three party process a routine or line of code is added into the hypertesct 

11 markiip language (HTML) code which defines the merchant's web page, particularity an 

1 2 order or transaction form page. The added routine issues a request for a machine data 

13 coUecdon(MDC) script to the third*party web dte\^enA^ 

14 by the customer's browser. When the script request is received by the madiine data 

1 5 archiving s^ce (MDAS), the archive service generates a unique transaction 

16 identification (TA/ED) and chedcsfi)r its own cookie. IfnoMDAS cookie is presient, the 

1 7 archive service sends a cookie to the requesting computer ialong with a machine data 

18 coUection(NlDC) script having the transaction ID embedd^te The MDC script is 

19 executed by the customer's browser, causing collection of certain data firom the 

2 0 customer's computer vtiiich is sent back to the ardiive service along with the transaction. 

21 ID and stored in a machme data profile in &ema(^edataai^ The transaction ID is 
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1 writtai into the transaction form, and when the 

2 merchutt web ^te, the transaction ID string becomes a part of tiie transaction data ncoid, 

3 along with customer identification, location,, and financial information. 

4 The machine data iidtiatty collected and stored m each profile prefeiably incudes 

5 the transaction ID, the apparent IP address of the customer's con^utea; a conveotioi^ 

6 jtii iF headtf which Id^itifies the customer's browser versions and certain eon^iration 
aspects ofthe browser, and the archive sice's coolde. the combination of sudi 
information, nunus the transaction ID, will be relativdy rare but may not be unique. 
Additionally, customers intoit on conducting fimidul«»it transactions often hide their IP 
acMress helimd HTTP proxies. In order to iiuther narrow the machine profile, in a 
preferred embodunent of tiie pieseait invention, the MDC script p^ims additional 
madiineprofiUng operations: generation ofamadime''fing^nnt'' and a proxy 
'^piermig" opoBtion. 

In the fii^erprint generation op^tion, the MDC script assembles an attribute 
strii^g formed by various attributes or configuration settings of tiie browser v^ch can be 
queried by the script The MDC script then performs a conversion process on the 
attribute string to generate a fingerprint string having content which is a fimction of the 
oiighial content of tiie atbibute string. The conversion proijess is preferably a liashii^ 
fonction which is, in effect, an krev^ble eaoyption algorithm. Hie generation of a 
conventional checksum is one example of a type of hadiitiig fimction. Foresaniple^ if the 
attribute striqg is formed by alphanumeric characters, the conveision process is peifoimed 
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1 on the String ofcodes representing the charact^. The particular conversion process or 

2 hashing function used tnay be one of many typ^s of conventional conversion algorithms or 

3 hashing Amotions, which are typically used for data integrity test^^ The resulting string 

4 from the MDC conversion process is a so-called fingerprint, which is returned to the 

I 5 archive service along with the transaction ID for storage in the nmchi^ A time 

6 value, queried from the customer computer time-of-day dock, is returned with tiie 

I 

7 fing^rint string and stored in conjunction therewith. 

8 An HTTP proxy is one of several types of proxies through which a browser may 

9 be setup to operate. Setting up an HTTP proi^ causes HTTP requests to be rdayed by- a 

10 primary gateway, through which the computer actuaUymter&ces to the internet, to 

11 renlote secondary gateway, or pro3^, with an IP address differed 

12 gateway]? address. Such redirection hides the true IP address of a computer. Theprpxy 

13 pierdng operation of the MDC script queries the customer cono^ut^ for any IAN (local 

1 4 area network) address which may be assigned to the computer and reads the system time 

1 5 of day clodc. Then attempts are made to send the IAN address, if any, the time value, 

1 6 and the transaction ID to the ardbive service mng a protocol v/bksk vM not be redirected 

17 through the HTTP proxy, for example a low^ level protocol such as TCP/IP or UDF 

18 protocols. ST^e attempt is successfiil, the message contah^ the time vahie, the 

1 9 transaction ID, and LAN address arrive at the archive s^ce wd> ate wilk the true return 

20 IP address of the customs computer, vMier an mir proxy mt^enes or not The 

21 IAN address and IP address 80 dotived are stored in Ihemachme profile. Itdiouidbe 

9 
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1 noted that the use of an HTTP proxy is not, of itself an indication of fraud. However, tlie 

2 acquisition of an additional IP address is one more pttameter with which to identify a 

3 particular computer. 
When^ and tlie customer submits the transactiim form to the metdiant, the 

transaction ID string is communicated to the mo-chant; along widi oth^ customer 
infonnatton su<^ as name, address, credit card number a^ 

information. The complete transaction record is stored oh the mjerchaot's system and is 
associated with a spedfic madhiiie idaitky profile within the arddve service by way of the 
transaction ID string. Thereafter, tiie stored machine identity profiles and transactbn 
records of luge numbers of transactions can be analy2sed by various fraud detection 
techniques to detect patterns of fraud and fraud idt^ts and, prel^tbty, identify and 
locate the soitfces of such activx^. 

The machme data profiles stored m the arcbhw service need not be combined with 
tiie customs identification information for non-suspidous transactions^ to tfaa:d>y 
present the privacy of non-su£^dous customers witiiin the madune data an^e. 
However, the processes of the present invention do not requke that the customer 
identification infi}nnation be k^t separated from any assodated machine data profiles, and 
there may be reasons to combme the assodated records. 
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1 Brief Description of the Drawings 

2 Fig. 1 is a simplified block diagram illustrating a plurality of custom^ and 

3 meiichant computers inter&ced to the internet along with a machine data archiving service 

4 computer for practicing the machine data collection process of the present invention. 

5 Pig. 2 is a sunplified blbdc diagram illustrating connection of a customs computer 

6 to the internet, vn&i optional components shown in phantom lines. 

7 Fig. 3 is a flow diagram illustrating prindpat steps of the machine data collection 

8 and archiving process according to the present invention. 

9 Fig. 4 is a flow diagram iUustratoig more detailed stq)s of the machme d^ 

1 0 collection and ardiiving process according to thie present invention. 

1 1 Fig. 5 is a flow diagram illustrating a still fiuther detailed steps iii the machine data 

1 2 collection and ardiiving process of ^e present ihventioa 

1 3 Various objects and advantages of this invention will become appar^t flnom the 

1 4 followii^ description taken in relation to the accompanyuig dmwi^gs wherdn are set 

1 5 forth, by way of illustration and example,^certain embodhneiits of this invention. 

16 The drawings constitute a part of this spedfication, include exemplary 

1 7 embodiments of the present invention, and illustrate various objects and features th^ eo£ 

18 ' • 
19 
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1 Petafled Description of the Ihventioii 

2 As reqiiired, detailed embodimeats of ihe pres^ invoition are disclosed haet^ 

3 however, it is to be understood that the disclosed embodim^ are merely exemplaiy of 

4 the invendon, which may be embodied in various i^rdas. Th^iefore, ^edfic structural and 

5 fimctional d^ails disdosed herein are not to be iitteipreted as iiinitiii^ but mei^ as a 

6 baaus ]fortiie claims and as a rqjresentidve bads for teadmig one sl^^ 

7 variou8fyaiq>loy the present uweotion in virtual^ any appropriatdfjr 
Sef^iiiig to the drawings in more detail: 
The riedG^ff^ice numeral 1 (Fig. 3) genoally deagnates 

a process for online collection of machine identifying or profiling data of conqmteis 
involved in comm^xaal transactions and for archiving such data to fidli£ate analysis fof 
fiaud detection purposes. The process collects machine idratifying or profiling data of 
conopitas mvdved in conunerdal transactions and ardhi^ 
madiine data archive service in assocration widi a transaction identification sttiQg or ID 
which is also writtoi into a transaction form of a men;hant with vtbom tiie customs is 
conducthig a transaction. 

Fig. 1 illustrates a plurality of host entities or merchants with corres^ondir^ 
mediant con4)uters 2, on wiuch are opoiated merchant w^ ates ivMck are accessible 
over a global computer networl^ such as tiie internet 4, by a plurality of customer 
con^utersS. The m^idiantcon^uters 2 ^»cute various programs whidi enable tiie sale 
ofprodocts or services by way oftheuiteniet 4. The mentet web sites 3 typically make 
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1 use of fonn type web pages with which the customers 5 interact by filling in various data 

2 fidds, for example, name, address, shipping address, telephone number, credit card type 

3 and number and e)qpiration date, and description and quantities of products to be ordered. 

4 The merchant transaction forms are usually written in hypertext maricup langu^e 

5 (HTML) and msy include requests for code written in other languages, su(^ as Java and . 

6 the like. When a customer 5 accesses a merchants transaction form, a transaction fomi 

7 file is communicated to the custom^s computer with various data fields displayed as fill- 

8 in boxes or the like. The customer fills in the appropriate fields and selects a submit 

9 "button" wMchiactivatesaroutmetotnmsferthecoUect^ 

10 merchant web sites for processing. The returned ''form" is a data record 6 which is 

1 1 : stored in a merchant transaction database 7 for retrieval and processing in due course ta' 

12 cause the ordered items to be gathered, packaged and prepared' for shiypment, along with 

1 3 finandal processing to debit the customer's credit account The finandal processtog may 

1 4 include a validity diedk of the o'edit account and an authorization check for the amount of 

15 purdiase with the credit card issuer. Additionally, inventory management processes are 

16 executed based on the itons withdrawn fi^om stock for shipment 

17 In a three party embodiment of the present invention, the process 1 makes use of 

18 an entity referred to herdn as a madihie data archiving service, MDAS or archive service, 

19 wfaidi operates an archive service computer system 15, induding an ardiive s^ce web 

20 site 16. Hie archive service system IS maintainis a madiine data archive service database 

21 or aitdiive 1 7 in whidi tiie machine data collection profiles 1 8 fi'om customs oonqnitos 5 
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1 dftii0 merchants 2 are Stored. ThemMvesemo&wfbatelCkiaiie^^ 

2 4. The ux^ye service 15 is preferably kulep^eitf 

3 by a merchants' association, a financial institution or assodation thereof; or may be an 

4 ind^pmdent contractor. Alt@nu(ttvely» it is conceivable a m^hant^ivitli a 1^ 

5 volume ofonline sales coddop^te its ovmiorhousenuu^e data profile coUection and 

6 ardMg service IS, &rftaudd^ection or possibfy for maiketingpfi^ 

7 Referring to Fig. 2, a customer cott^utersyst^Sindudes^ 

8 20 into&ced to the intonet 4 byvfsy of a piimaiy gateway 22, as of an int^et sendee 

9 provider (ISP). The computer 20 might be one ofmaiQr on a local area network or IAN 

10 24 which indudes a rout^ or svntch which routes data from the infemet 4 to tiie 

11 conpitereontiien^oik. Ilie computer 20 may commimicate through the mternet 4 by 

12 wayofalHTP (hypertext tranafiar protocol) projgr 26, wWchdisg^ 

13 protocol (IP) address ofthe actual gateway 22. The computer 20 accesses web sites on 

14 ihs internet 4 usoig a customer web browse 28 v^di proc^ses BTML language and 

15 various other standard w^ oriented languages to display or othow^ 

16 ofwd} pages and interact therewitlL The browso* 28 is normally enabled to accept 

1 7 "cookies'' 30 which are stored m a cookie file. Cookies 30 are data strings which are 

1 8 issued by web sites and gK^ an kdication of a previous -nsa^ to a particular web site and 

1 9 may indicate a particular configurodon or set of preferences of the customer's setup of the 

20 con^ut^20. TypicaUy.&e customs conpiter 20 has a time of day dodc^c^ 
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1 The customer computer 20 may have a £>ced IP address, depending on the manner 

2 in which it is inter&ced to the internet More commonly, tiie customer computer 20 wilt 

3 have a temporary or dynamically assigned IP address which is determined by the primary 

4 router22. The pnmaryrout^ 22 has an IP address, as do a router of a LAN 24 or an 

5 HTTP proxy 26 if dther is present in the custom^s con^uter system 5. 

6 Fig. 3 illustrates the prindpal actions or steps of a general or basic process 34 of 

7 the process 1 for coUecticg machine identifying data from customs computers 5. At step 

8 35, at least one machme identifying profile parameter is captured upon access of a 

9 customer computer S or other online access device with a host or m^chant wd) ^te 3. A 
1 0 unique transaction identifier or TA/ID is generated at 36 and assodated at 37 with the 
11' captured profile parameter. The transaction ID is also assodated at step 38 vntk a 

-12 transaction record generated as a result of the mteraction or transaction conducted 

13 betwera the customer computer Sand a merchant web site 3. Although not spedfically 

1 4 shown in Fig. 3, the process 34 may capture machine profile data that is passed fi'om the 

1 5 customer computer 5 to the merchant computer 3 as an inherent step of the customer 

1 6 computer S accessmg the merchant computer 3. Altemattvety, the process 34 may pass 

1 7 routines to the customer compute S to cause it to ''self-identify" itself by querymg certam 

1 8 configuration parameters and passing such mfonnatibn to a machme profile stored either 

19 withm the merdianfs system 2 or in a third party archive 17. The process 34, timg^ 

2 0 encompasses a two-party embodunent or a three party embodiment of the machine data 

21 collection and ardiivii^ process 1 of the present invention. 

15 
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1 Ref^rmgparticnilarlytoFig. 4, amoreparticdarthreepaiiye^^ 

2 maclilne data cottection and arduving piocesis 1 b^ins at step 40 with the coding ctf a 

3 iMchine data colliection(MDC)saipt request i^^^ 

4 fonn of a merdiant web dte 3. When a customs 5 accesses the merdiant transaction 

5 fimn at step 42, the customer bnmser 28 processes the transact 

€ the MDCsoipt request, vduchcames the MDCsoipt request to be conimutdcat^ 

7 arditve service web dte 16 at step 44. The script request aixiyes at tiiearduve service 15 

8 with a set of customer machine parameters which prindpally pro^de a return path for the 

9 MDC so^t from the arc^btvesavice 15 to tiie customer 5. Tlie customer noad^ 

1 0 parameter set preferabty inchides "user ag^it" information, wbkh is the vemon of tiie 

11 customs browse 2S. 

12 At step^ 46, tiie ardiive service 15 geaerates a unique transaction ID string and 

13 associates it witii the customer madhine parameter set in the MD AS ardbive 17. At step 

14 48, the an^vesaifice returns the ^dDC script, with the transaction ID emb^dedT^^ 

15 i^ to the customer browser 28. At st^ 50, the customer browser 28 processes the MDC 

1 6 soipt -wtacii. Bit a mmimum, writes the transaction ID string into Hie merdiant's transaction 

17 fbnn. Assumii^ that the customs 5 completes the transaction and submits the transaction 

1 8 form to the modiant 2 at step 52, the transaction ID string'ls stored with the transaction 

19 data record 6 in tiie merdiant transaction database 7. The transaction ID, thus, indirectly 
2 0 associates the machine data parameter set 18 stored in the MDAS arehive 17 at stq> 54 
21 witii the customer idoitiiyinfonmition stored widi the traosadbn data i«0Qid 6 
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1 merchant's transacdon database 7. Thereafter, qualified parties may access Ihe MDAS 

2 ardiive 17 for information related to a transaction ID. 

3 The MDAS archive 17 need not contain any information which spedfically 

4 id^itifies a particular customer, only the madiine parameter profiles 18 vnih associated 

5 transaction ID strings. Ilie MDAS ardirve records 18 can be anafyzed in conjunction with 

6 the merchant transaction records for patterns offimid or for other purposes. The great 

7 majority of MDAS archive records can be puiged fix>m the an^e 17 a&st a selected 

8 period of time. Any records which are assodated with any transaction irregularities or^ 

9 suspidonsofactualfimidmaybereta&edloiig^. 

1 0 Fig. 5 illustrates the prindpal stqis of a preferred embodiment 60 of the madiine 

1 1 data collection and archiving process 1 of the present inventioa The process 60 b^ins 

12 witii the addition at 62 of a machme data collection (MDC) soipt to the transaction (TA) 

1 3 fi^rm page code of a merchant web site 3. The ^ansaction form page code is processed at 

14 64 by a customer browser 28 iff^eii the iherc^ant web page is accessed to therdjyrequ^ 

15 tiie MDC script at 66 fi-om the Machine data ardiive service (MDAS) web ^e 16. When 

16 the brdfv^ 28 accesses the MDAS web site 16, requestii^ the mix: smpt, the MD 

17 web site checks for the presence of an MDAS cookie at step 68. If no MDAS cookie is 

1 8 detected, an MDAS coolde is genoated at 70 and a unique'transaction idrattification 

19 (TA/ID) string is generated at 72. TheMDC script, transactionID, and coolde, if not 
2 0 previously set, are returned at 74 to the customer browser 28, ihe transaction ID being 
21 embedded wttlim the MDC so^ 

17 
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1 When the MDC script is received by the browser 28, it is executed at 76. The 

2 cookie is stored m the ^ookie file 30, orpossihly in the mranoiy of the customer computer 

3 20. Execution ofa preferred MDG script causes sevwal actions to be performed. The 

4 MDC script writes tibe transaction ID into the transaction form at step 78. The so^ can 

5 do this by ettii^r setting an existing variable (^an appropriate name to the t^^ 

6 string or by writing an appropriate variable into the transaction form page and se^^ 

7 vahie to the transaction n> string. Additional, the preferred MDCsa:q>tgenmtes a 

8 "fing^rint^ of the customer computer 20 at step 80 and attempts to perform a pro^gr 

9 pierdi^ operation at step 82. 

10 Li generating tiiemadiinefingeiprint at 80, tiiel^C script queries the browse 28 

11 for a mmiber of attributes and settings and concatoiates the results into an attribute string 

12 at 84. The MDCsoipt then peiforms a hashmgalgofitiim on the attribute string at 80 to 

13 generate a fingerprint string wM(^ has a lug^ degree of uniqueness. Huihu^fimctionsaTe 

1 4 irreversible enoyption processes in whidi the result is dependent on the orighial content of 

15 the data on which the hashing algoridim is operated. Bashu^fiinctionsarecommonljr 

16 iisedlbrdatamt^pnlydieddng. As pre\dousfy stated, a common diedcsum is the result 

17 of a type of hashmg fimction. The particular hashing function employed pre&rably 

18 ma»mi2»s the uniqueness of the resulting fingeiprint 

19 At step 86, the customer computer dock 32 is quoied for a current time Value. At 

20 step 88, the fingerprint, the transaction ID, and tile tune vahie are conmnmicated to the 

18 
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1 MDAS web site 16 along with an HTTP header with cookie and ''apparent IP address, all 

2 ofwfaich are stored as 9 machine data pro£3e IJS within the 

3 At step 90, the mix; script adds a proxy piercer request to the transacti^ 

4 which, when executed by the browser 28 at step 92, sends a request for a proxy piercer 

5 applet or code to the MDAS wd> site 16. When the prossy piercer applet/code is executed 

6 by the browser 28 at 94, a time value from the clock 32 is again queried at 96 and any 

7 ^stiiig local area network (LAN) address is queried at 98. At step 100, the proxy pi&rcec 

8 applet/code sends the time value, the LAN address (tf any), and the transaction ID to the^ 

9 MDAS web site 16 by a protocol which bypasses any existing HTTP proxy 26. The 

10 protocol used is one which is at a lower level than HTTP, such as UDP (user datagram 

11 protocol) or, preferably, TCP/IP (transmission control protocol/intemet protocol). 

12 Bypassing the HTTP proxy 26 causes the data sent in step 100 to airive at the 

1 3 MDAS web site 16 witii the IP address of the piimaiy gateway 22, which may be different 

14 fi-om any apparem IP addri^spreviousfy recorded if anHTTP pro Ifihe 

15 proxy piercer procedure 82 is successfiil, the primary gateway IP address is stored at step 

1 6 102 within the machine data profile 18 identified by the transaction ID. It should be noted 

17 that some types of proxies, such as some types of firewalls, may block all non-HTTP 

1 8 protocol packets, so tiiat the proTcy pi^icer procedure 82 migjit not be successfiil in all 

19 cases. 
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1 ifthe customer coinpletes the transaction with the merchant w 

2 transaction form is submitted at step 104, \vfaich causes the transaction record 6, inchiding 

3 the transaction ID^ to'be stored at step 106 in the merchant database 7 for processing. 

4 Following are examples of code for an MDC s&^t, as from steps 40 or 62. 

5 Assuming the machine dat^ ardiiviqg service or MDAS web ^ 16 has the fictional URL 

6 (uniform resource locator) 63£ample'Uri.net and a spedficmerdbant has a mercha^ 

7 ideiidfier l/SMM, a line of HTML code is added at st^ 40 to the transaction form of 

8 merchant MMM between the <foraP^ and <yfonn>HIMLt^ 
9 

10 <sci:q»tsroHhtQ)s7/www.example^iri.net/s/7MMM>^ 
11 

12 Whm the customs brows^^ 28 processes the transaction foim at step 42, it 

13 requests a soipt file fiom the source URL: https:/Avww.example-uri.net/s/?MMM 

14 At step 44, the customef web browse 2S requests the MDC scn|)t by wic^f^th^ 

15 HTTP protocol The HTTP request indudestiie merchant ID MMM, the user agent 

16 (browser version), the IP address offhe customer's HnPpro:^, and an^ HTTP cookies 

17 previousl7senttothecustomerbywww.example-uri.net Upon receiving this 

1 8 information, the arcUve sovice 16 records tids infonna^oil in a madune data record 

19 whidi also indudes the transaction ID. 

20 Upon recdving the file request, the archive service 16 genontes a unique 

21 tnuisactic«ID(i«preseiitedbdowas2ZZ)8t8tep46tobea8sodatedwt^ 
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1 and the machine parameter set. An exemplaiy transaction ID is a string of 24 letters and 

2 digits. Thefii^eight digjtsfonnatime-stamp.T^^chisahexadedmalrepresiratationof 

3 the seconds elapsed since nudni£^ Jamiaiy 1, 1970 UTG (coordinated univeml time). 

4 Lithe preferred embodiment ofthe process 1, the MDC script is written in an 

5 ECMAScaipt compliant language, sudi as JavaScript, JSciipt, or VBScn|)t A JavaScrqtt 

6 version ofthe MDC script is as follows Oinebreaks and indentations added fi>r daiity): 
7 

8 doamient.write("<1nputname==transactionidtype=luddenvdue?=2Z^ 

9 • • ■ 
10 d=^ewDateO; 

11 

12 t==3600M.getHoursO+60*d.getMttnites()+dgetSecondsO; 

13 

14 documeiit.write("<imghdsih^=l widdF^l sroNitQjs'y/www.esample- 

15 uri.net/i/?i=ZZZ&t="+t+">"); 
16 

17 document,write("<appIet height^l width=l 

18 codrf)ase=4itQ)S.7/www.exampIe-iirl.net/ 

19 code»a/?ZZZ> 

20 <^aramname=4vahie=^ZZXappIet>"); 
21 
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1 Hie exemplaiy MDC soipt includes the unique transaction ID value in sev^ 

2 places. the script eseimtes on the customer conpiter 20, it urates BI^ 

3 the metchanfs order fi>fin. Spedficalty: 

4 1> The script adds a hidden variable called "transactiomd" to the merchant's 

5 tfansaiCtionfonnand asagnsitthevahieQfthetrans^ When the 

6 transaction form is submitted, the merchant recdves the transaction II> and can associate 

7 it with tiie transaction data record. 

8 2) The script computes the seconds dapsed since nndnight on tlieclo^ 

9 and writes a request for a 1 pixel b}rlidxdunage. Ihduded hi the request is the 

10 transaction ID and the time value. When the request executes, this data is s^ bade to the 

1 1 ardnve service 16 and recorded vnthihe transaction ID in tiie MDAS ardiive 17. 

12 3) The script adds a request for a program located at the arduves^ce weh 

13 site 16 vdiidi,m this example, is a Java applet The applet downloads to the cu^omer 

14 conqmta:20 fit)mthe arduve service 16 and executes, iq>pearii)g as a 1 pixdby 1 pisd 

15 image on the transaction form. Hie transaction ID is passed to die program as a 

16 parameter spedfiedm the SCTipt. The program performs three tadss: 

17 a) it calculates TTT, the seconds elapsed since midnight on the system dock 

18 32; 

19 b) it calculates AAA, tiie address ofthe customer 20 on its own local area 

20 networic24;and 
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1 c) it sends this data back to the archive service 16 via TCP/SPy by requesting 

2 the following IBRL: 

3 http://www,example^^^ 

4 The archive service 16 receives the message wliich includes the parameters TTT^ 

5 AAA, and ZZZ, The message also mdudestiie IF address of the sender. This address is 

6 the customer's actual IP address, which in some cases is differ^t from the HTTP proxy IP 

7 address. The archive service 16 records this mfonnation in the MDAS archive 17 and 

8 associates it with the transaction ID ZZZ. 

9 The machine data collection and archiving process 1 of tiie present invention has 

1 0 been described with a particular application in fraud detection. However, it is foreseen 

1 1 that the techniques of the present invention have a wider application, as for marketing or 

1 2 computer support purposes, or other fimctions. Wlule the process 1 has been described 

1 3 with reference to the internet 4 or world wide web, it is also concdvable that the process 1 

1 4 could be employed on computer networks of less tfaian ^obal expanse, such as a laige 

1 5 intranet a national or regional networl^ or the like: 

1 6 Therefore, it is to be understood that while certain fomis of the present invention 

1 7 have been illustrated and desoibed herem, liie present mvention is not intended to be • 

1 8 limited to the specific forms, arrangement of parts, sequence of steps, or particular 

1 9 applications described and shown. 
20 
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What is claimed and desired to secure by Letters Patent is: 
1. A process for coUectinginadiineidettti^TOg infold 

onliae access device used for substantially anonymou^ accessing a host coiiq>uter 
^stem over a digital network, said host computer system generattog an interactiott 
record of an access therewith by said access device, and said process coii^riang 
the steps of. 

(a) cqrturing a madhme identifying profile parameter upon said access device 
accessmg said host con^niter system; 

(b) generating a unique mteraction identification string upon said access device 
aecesshig said host counter syst^ 

(c) associating said interaction identification string with said profile parameter, 
and 

(d) associating said kteraction identification string with said interaction record 
g^erated upon sud access device accesang said host computer qrstem 

2. A process as set forth in Clahn 1 wha-dm said capturing step includes the step o£ 
(a) capturing a digital address ofsaid access de^ce on said digital netwoilc 

3. A process as set forth mClaunlwherehi said capturing step hichides the step o£ 
(a) «9>tuiing a configuration setting of said access device. 
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4. A process as set forth in Claim 1 and including the steps of 

(a) commuQicating a self-identification routine to said access device upon said 
access device accessing said host computer system; 

(b) said access device executing said self-identification routine; 

(c) said sel&identificaticm routine, queiying a configuration settiiDg of said 
access device to. derive said profile parameter; and 

(d) said sdf-identification routine communicating said profile parameter to a 
remote location for assodation with said interaction identification string.^ 

5. A process as set forth in Claim 1 and including the steps o£ 

(a) said host system operating a host web site including an intmction page 
generated by interaction page code processed by said access device upon 
accessing said host web site; and 

(b) codmg, withm said interaction page code, a self-identification routine 
which causes said access device to communicate said profile parameter 

when said access device processes said interaction page code. 

» 

6. A process as forth in Claim 3 and induding^efitepof 

(a) coding said seif4d»itifi<»tiott routine in su<^ a manner tlmt said 

paramet^ and said intmction identification string are communicated to a 



25 



wo 01/97134 



PCT/USOl/18076 



third party web she at which said profile parameter and said interaction 
identification string are stored. . 

7. A process for identi^g a customer computer involved in an online transaction 
between a customer waog a customer brovraer op«:afing on said customs 
computer and a merchant operating a merdiant web site, said method compiisii^ 
the steps o£ 

(a) capturing a customs computer profile parameter upon said customer 
computer accesang said merdiant web site; 

(b) genmting a transacdon identification string and assodating said string 
witii said parameter; 

(c) storing said parameter^ said string in a madiine data archive; 

(d) upon sdd customer conflicting a transaction tiuou^ said nteirdiant web 
8ite» storing said transaction identification strimg witii a transaction record 
formed during said transaction to th^eby assodate sdd parameter \mth 
ssid transaction record through sdd string. 

8. A process as set fi>rtii in Claim 7 wlierdn said captdiing step indudes the ste|> o£ 
(a) capturiqg an IP address of said customer cqmpater. 
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9. A process as set forth in Claim 7 wherein said capituring step includes the step o£ 
(a) capturing a configuration setting of said customer computer. 

10. A process as set forth in Claim 7 and including the step of: 

(a) communicating said profile parameter and said transaction ideutifieafion 
string to a third party web site for storage. 

11. A process as set forth in Claim 7 and inchiding the step of: 

(a) causing said customer computer to communicate said profile parameter and 
said transaction identification string to a third party web site fi)r storage. 

12. A process as set forth in Claim 7 and including the steps of: 

(a) communicating a self-identification routine to said oistomer computer 
upon said customs computer accessing said merchant web site; 

(b) . said customer computer executing said self4dentificationroutine;^ 

(c) said self-id^itification routine querying a configiuA 
customer computer to derive said profile panunet^ and 

(d) said self-identification routine communicatiiig said profile parameter to a 
remote location for assodation witii said interaction identification string. 
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13, A process M set forfh in Oaim 12 and mcdudingihe Step o£ 

(a) csoding said self-identification routine in sucli a manner that said proflfo 
parameter and said interaction idaitification string are comrattnicated to a 
third party wd) site at which said proftte parameter and said interaction 
fdeniificatio& string are stored. 

14. A process as set forth in Clahn 12 wherein said querying step inchides the steps of: 

(a) querying said customer browser for a plurality of configuration settings; 

(b) forming an attribute string fiom said phuafity of configunrtionsetth^ 

(c) processing said attribute string toft>nn said profile parameter of said 
customer computer. 

15. AprocessassetforthinClaiml2wherein8aidcustomercomput«potentjatty 
accesses said merchant web site by way of a proxy, and said commmacating step 
includes the steps o£ 

(a) communicating said profile parameter and said transaction ideittfficatiott 
string to said remote web site using a protocol which bypasses said proxy. 

16, Apiocessforidentifyfagacustomercomputerinvoh^manonlmotransactton 
through a merchant web rite between a customer uang a customer browser 



28 



wo 01/97134 



PCT/DSOl/18076 



Operating on said customer computer and a merchant who operate said web site, 
said method comprising the steps of 

(a) coding a script request within a transaction fomi of said merchant web site; 

(b) processing said script request by said customer browser upon accessing 
said merchant web site to thereby communicate to an archiver web mte of a 
machine data archivmg sendee an electronic request fi>r a machuie data 
collection script; 

(c) said archiver vrdb site retummg said script to said customer browser along 
with a unique transaction identification string; 

(d) said customer brpwser processing said script to thereby cause said script to 
query said customer computer for a profile parameter of said customer 
computer, 

(e) said script caudng said customer browser to communicate smd profile 
parameter and said transaction identification string to said ardbiver web 
site; 

(f) said archiver web site storing said profile parameter and said transaction 
identification string in a machine data profile; 

(g) said script causing sdd customer browser td write said transaction 
identification string into said transaction form; and 

(h) upon said customer adtSng oistom^ identification mfonn^on to said 
transaction form and electronically submittmg said transaction form to said 
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m^(^hatit wd) ate to therd)y comprise a transaction 1^ 

transaction identification- string assodating said transaction record with said 

maciune data profile. 

17. A process as set fbrfii in Claim 16 and'inchi(fing the s^s q£ 

(a) said script causing said computer browser to communicate said profile 
parameter and said transaction idoitificafion string along with a 
conventional liypertext ixansf^ protocol (HTTP) head^ and 

(b) said archiver sendee additional storing said HTTP header in assomtion 
witii said madune data profile. 

18^ Aprocessassetfi)rthin0unil6andincludii%&est^o£ 

(a) said soipt querying said customs browso* fot a configuration setting 
tii«iea£ 

19. A process as set fiirtii in Claim 15 and induding the steps o£ 

(a) said script queow« said customer browser fijr a plurality of configuration 

settings; 

(b) said script fi)rming an attribute string flwm said pluralily of configuration 
settings; and 
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(c) said script processing smd attribute string to form said profile parameter of 
said customer computer/ 

20. A process as set fordi in Claim 19 wherein said script processing step includes the 
step o£ 

(a) said script performing a hashing fimction on said attribute string to form 
said profile parameter. 

21. A process as set forfii in Claim 16 wherdn said customer computer potentially 
accesses said m^hant web site byway of a pro^gr, and including the step o£ 
(a) said script communicating said profile parameter and said transaction 

Identification string to said archiver s^ce web site usii^ a .protocol which 
bypasses said proxy. 

22. A process as set forth in Clakn 16 and mdudiqg the step of: 

(a) said script communicating said profile parameter to said archiver service 
web site usmg a protocol other than HTTP. 

23. A process as set forth m Claim 16 v/hec&n said customer con^uter indudes a 
digital clock, and inchidmg the steps of: 
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said scsr^t caunng said customs browser to query said dock for a time 
value; and 

said script causdng said customer browser to send said time value to said 
ardiiver service web site along witli said profile parameter. 

24. A process for id^tiQfing a customer computer involved in an online teantsaclioii 
through a merdiant web site between a customer using a custoiner browser 
opiating on said customer computer and a merchant who operates said web site, 
said method eon9>risii^ the st^s o£ 

(a) codiqg a script request within a transaction form of said m^x^ant web site; 

(b) processing smd script request by said customer browser upon accessing 
said merdiaiit web site to therdjy conmiunicate to.an archiver web si^ 
machine data ardbivii^ service an electronic request fbr a madune data 
collection smp^ 

(c) said archiver web site returning said script to said customer browser along 
with a unique transaction id^itification striog; 

(d) said customer browser processing said saipt to thereby cause said script 
to: 

(1) query said customer browser for a plurality of configuratioii 
setting; 

(2) finm an attribute striiigftom said plu«% of coii^irationsettii^ 



(a) 
(b) 
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(3) p^onn a hasliingfimction on said attribute string to foim said 
profile parameter, and . 

(4) query an internal digital dock of said customer computer for a 
current time value; 

(e) said script causing said customer browser to communicate said profile 
paramet^, said time value, and said transaction identification string to said 
archiver web site along with a conventional HTTP header; 

(f) said archiver web site storing said profile parameter, said time value, and 
said transaction identtScation string in a machine data profile; 

(g) said script causing said customs browser to write said transaction 
identification string into said transaction form; and 

(h) upon said customer adding customer identification information to said 
transaction form and electronically sobmittii^ said transaction form to said 
m^hant web site to thereby comprise a transaction record, said 
transaction id^itification string assodating said transaction record with said 
machine data profile. 

25. A process as set forth in Clahn 24 wher^m said customer computer potentially 
accesses said m^chant web site by way of a proxy, and including the steps o£ 
(a) said script querying said customs computer for a second profile parameter, 
and 
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(b) said scnpt comtnonicatiiig said second profile jHttamet^ and said 

transaction identification string to said archives s^ce wrfr site usang a 
protocol vvld<& bypasses said prcHgr. 

26. A process as set forth in 0sm 25 and induding the step o£ 

(a) said script conuminicating said second profile paramet^ to said {^rchiver 
service web tste mang a protocol other than HTTP. 
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